home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-x400ops-mgtdomains-ops-03.txt < prev    next >
Text File  |  1993-03-03  |  29KB  |  916 lines
  1.  
  2.  
  3.  
  4.    Operational Requirements for X.400 Management Domains
  5.  
  6.                   in the GO-MHS Community
  7.  
  8.                      December 21, 1992
  9.  
  10.                       Robert A. Hagens
  11.  C=US; ADMD= ; PRMD=INTERNET; DDA.RFC-822=hagens(a)ans.net;
  12.                        hagens@ans.net
  13.  
  14.                          Alf Hansen
  15. C=no; ADMD= ; PRMD=uninett; O=sintef; OU=delab; S=Hansen; G=Alf
  16.                  Alf.Hansen@delab.sintef.no
  17.  
  18.                      $ Revision: 1.15 $
  19.  
  20.  
  21.  
  22.  
  23.                     Status of this Memo
  24.  
  25.  
  26. This  document  specifies  a  set  of  minimal   operational
  27. requirements  that  shall  be  implemented by all Management
  28. Domains (MDs) in the Global  Open  MHS  Community  (GO-MHS).
  29. This  document defines the core operational requirements; in
  30. some cases, technical detail  is  handled  by  reference  to
  31. other documents.
  32.  
  33. The GO-MHS Community is defined as all  organizations  which
  34. meet the requirements described in this document.
  35.  
  36. This document is an  Internet  Draft.  Internet  Drafts  are
  37. working  documents  of  the  Internet Engineering Task Force
  38. (IETF), its Areas, and its Working Groups. Note  that  other
  39. groups  may  also  distribute  working documents as Internet
  40. Drafts.
  41.  
  42. Internet Drafts are draft documents valid for a  maximum  of
  43. six  months.  Internet  Drafts  may be updated, replaced, or
  44. obsoleted by  other  documents  at  any  time.   It  is  not
  45. appropriate  to use Internet Drafts as reference material or
  46. to cite them other than as a "working  draft"  or  "work  in
  47. progress."
  48.  
  49. Please check the I-D  abstract  listing  contained  in  each
  50. Internet Draft directory to learn the current status of this
  51. or any other Internet Draft.
  52.  
  53. When agreement is reached, it will be submitted to  the  RFC
  54. editor  as  an  informational document. Distribution of this
  55. memo is unlimited. Please send comments to the authors or to
  56. the discussion group:
  57.  
  58.  
  59. INTERNET-DRAFT (OPS-1)    [Page 1]       Exp. Date: 05/10/93
  60.  
  61.                 ietf-osi-x400ops@cs.wisc.edu
  62. C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=ietf-osi-x400ops
  63.  
  64.  
  65.  
  66.  
  67.  
  68. Beginning with version 1.9, this  document  contains  change
  69. bars  which  indicated  changes  that have been made. Change
  70. bars only reflect the changes  from  the  previous  version.
  71. Change bars appear to the right of the text. Deleted text is
  72. not shown.
  73.  
  74. Pervasive changes are not denoted with change bars. However,
  75. they  are  noted at the beginning of the document. Pervasive
  76. changes from version 1.8 to 1.10 are:
  77.  
  78.      o
  79.      The phrase "International Service"  has  been  replaced
  80.      with "International X.400 Service".
  81.  
  82.      o
  83.      References have been cleaned up.
  84.  
  85.      o
  86.      Section 2.3 has been extensively rewritten.
  87.  
  88. Pervasive changes from version 1.10 to 1.13 are:
  89.  
  90.      o
  91.      The  phrase  "International  X.400  Service"  has  been
  92.      replaced with GO-MHS Community.
  93.  
  94. Pervasive changes from version 1.13 to 1.14 are:
  95.  
  96.      o
  97.      The phrase "IMD" (Internet Management Domain) has  been
  98.      replaced with GO-MD (Global Open Management Domain).
  99.  
  100.      o
  101.      The phrase "Internet mail service"  has  been  replaced
  102.      with RFC-822 mail service.
  103.  
  104.      o
  105.      The references are cleaned up.
  106.  
  107.      o
  108.      Section 3.1.2 has been  rewritten.   
  109.  
  110. Pervasive changes from version 1.14 to 1.15 are:            |
  111.  
  112.      o                                                        |
  113.      Figure 1 is drawn with ASCII characters.                 |
  114.  
  115.  
  116. INTERNET-DRAFT (OPS-1)    [Page 2]       Exp. Date: 05/10/93
  117.  
  118.      o                                                        |
  119.      The Example of the Community Document is removed.        |
  120.  
  121.      o                                                        |
  122.      Reference [9] is new.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. INTERNET-DRAFT (OPS-1)    [Page 3]       Exp. Date: 05/10/93
  174.  
  175. 1.  Introduction
  176.  
  177. There  are  several  large,   operational   X.400   services
  178. currently  deployed. Many of the organizations in these ser-
  179. vices are connected to  the  Internet.  A  number  of  other
  180. Internet-connected  organizations  are  beginning to operate
  181. internal X.400 services (for example, U.S. government organ-
  182. izations  following  U.S.  GOSIP).  The  motivation for this
  183. document is to foster  a  GO-MHS  Community  that  has  full
  184. interoperability  with  the existing E-mail service based on
  185. RFC 822.
  186.  
  187. The goal of this document is to  unite  regionally  operated
  188. X.400  services  on  the  various continents into one GO-MHS
  189. Community (as seen from an end-user's point of view).  Exam-
  190. ples of such regional services are the COSINE MHS Service in
  191. Europe and the XNREN service in the U.S.
  192.  
  193. A successful GO-MHS Community is dependent on  decisions  at
  194. both  the  national  and international level. National X.400
  195. service providers are responsible for the implementation  of
  196. the  minimum requirements defined in this document. In addi-
  197. tion to these minimum  requirements,  national  requirements
  198. may be defined by each national service provider.
  199.  
  200. This document refers to other  documents  based  on  ongoing  |
  201. work,  which   will  be  published as Prototype and Informa-  |
  202. tional RFCs. These documents are:
  203.  
  204.  
  205.     o Routing  coordination  for  an  X.400  MHS-service
  206.     within  a multi protocol / multi network environment
  207.     [1].
  208.  
  209.     o Co-ordination Procedures  for  RFC  1327  Gateways
  210.     [4].
  211.  
  212.     o Postmaster Convention for X.400 Operations [9].     |
  213.  
  214.  
  215. This document handles issues concerning X.400 1984 and X.400
  216. 1988  to 1984 downgrading. Issues concerning pure X.400 1988
  217. are left for further study.
  218.  
  219. We are grateful to Allan Cargille and Lawrence Landweber for
  220. their input and guidance on this paper. This paper is also a
  221. product of discussions in the IETF X.400 Operations  WG  and
  222. the RARE WG1 (on MHS).
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230. INTERNET-DRAFT (OPS-1)    [Page 4]       Exp. Date: 05/10/93
  231.  
  232. 1.1.  Terminology
  233.  
  234. This document defines requirements, recommendations and con-
  235. ventions.   Throughout  the  document, the following defini-
  236. tions apply: a requirement is specified with the word shall.
  237. A  recommendation is specified with the word should.  A con-
  238. vention is specified with the word might.   Conventions  are
  239. intended  to make life easier for RFC 822 systems that don't
  240. follow the host requirements.
  241.  
  242.  
  243. 1.2.  Profiles
  244.  
  245. Different communities have different  profile  requirements.
  246. The following is a list of such profiles.
  247.  
  248.     o U.S. GOSIP - unspecified version
  249.     o ENV - 41201
  250.     o UK GOSIP for X.400(88)
  251.  
  252. In the case when mail traffic is going from the RFC-822 mail  |
  253. service  to  the  GO-MHS  Community, the automatic return of  |
  254. contents when mail is non-delivered should be  requested  by
  255. RFC  1327  gateways  and should be supported at the MTA that
  256. generates the non-delivery report.  However,  it  should  be
  257. noted  that this practice maximizes the cost associated with
  258. delivery reports.
  259.  
  260.  
  261. 2.  Architecture of the GO-MHS Community
  262.  
  263. In order to facilitate a coherent deployment of X.400 in the
  264. GO-MHS  Community  it  is  necessary  to  define, in general
  265. terms, the overall structure and organization of  the  X.400
  266. service.   This  section  is broken into several parts which
  267. discuss management domains, lower layer connectivity issues,
  268. and overall routing issues.
  269.  
  270. The GO-MHS Community will operate as a single MHS community,
  271. as defined in [1].
  272.  
  273.  
  274. 2.1.  Management Domains
  275.  
  276. The X.400 model supports  connectivity  between  communities
  277. with different service requirements; the architectural vehi-
  278. cle for this is a Management Domain. Management domains  are
  279. needed   when   different   administrations  have  different
  280. specific requirements.  Two types of management domains  are
  281. defined  by  the  X.400  model: an Administration Management
  282. Domain (ADMD) and a Private Management Domain (PRMD).
  283.  
  284.  
  285.  
  286.  
  287. INTERNET-DRAFT (OPS-1)    [Page 5]       Exp. Date: 05/10/93
  288.  
  289. Throughout the world in various  countries  there  are  dif-
  290. ferent  organizational policies for MDs.  All of these poli-
  291. cies are legal according to the X.400  standard.  Currently,  |
  292. X.400  service providers in a country (inside or outside the  |
  293. GO-MHS Community), are organized as:
  294.  
  295.     a) One or several ADMDs.
  296.     b) One or several PRMDs and with no ADMDs present in the country.
  297.     c) One or several PRMDs connected to one or several ADMDs.
  298.  
  299.  
  300. Or in combinations of a), b) and c).  At this  stage  it  is  |
  301. not  possible  to  say  which  model  is the most effective.
  302. Thus, the GO-MHS Community shall allow every model.
  303.  
  304.  
  305. 2.2.  The Well Known Entrypoint (WEP)
  306.  
  307. The X.400 message routing decision process  takes  as  input
  308. the  destination O/R address and produces as output the name
  309. (and perhaps connection information) of  the  MTA  who  will
  310. take  responsibility  of delivering the message to the reci-
  311. pient. The X.400 store and forward model permits  a  message
  312. to  pass  through  multiple  MTAs.  However, it is generally
  313. accepted that the most efficient path for a message to  take
  314. is one where a direct connection is made from the originator
  315. to the recipient's MTA.
  316.  
  317. Large scale deployment of X.400 in the GO-MHS Community will
  318. require  a well deployed Directory infrastructure to support  |
  319. routing. In the GO-MHS Community X.500 is considered  to  be  |
  320. the  best  protocol  for  such  an  infrastructure.  In this
  321. environment, a routing decision can be made by searching the
  322. X.500  directory  with a destination O/R address in order to
  323. obtain the name of the next hop MTA.  This MTA may be a cen-
  324. tral  entry  point  into an MD, or it may be the destination
  325. MTA within an MD.
  326.  
  327. Deployment of X.400 without X.500 will require  the  use  of
  328. static  tables  to  store  routing  information.  This table
  329. (keyed on O/R addresses), will be used to map a  destination
  330. O/R address to a next hop MTA.  In order to facilitate effi-
  331. cient routing, one could build a table that contains  infor-
  332. mation  about  every  MTA  in every MD.  However, this table
  333. would be enormous and very dynamic, so this is not  feasible
  334. in  practice.  Therefore, it is necessary to use the concept
  335. of a well known entrypoint (WEP).
  336.  
  337. The purpose of a WEP is to act as a default entry point into
  338. an MD. The MTA that acts as a WEP for an MD shall be capable
  339. of  accepting  responsibility  for  all  messages  that   it
  340. receives  that  are  destined for well-defined recipients in
  341. that MD.
  342.  
  343.  
  344. INTERNET-DRAFT (OPS-1)    [Page 6]       Exp. Date: 05/10/93
  345.  
  346. The use of a WEP for routing is defined by [1]. WEPs in  the
  347. GO-MHS Community shall route according to [1].
  348.  
  349.  
  350. 2.3.  Lower Layer Stack Incompatibilities
  351.  
  352. A requirement for successful operation of the GO-MHS Commun-
  353. ity is that all users can exchange messages. The GO-MHS Com-
  354. munity is not dependent  on  the  traditional  TCP/IP  lower
  355. layer  protocol  suite.  A variety of lower layer suites are
  356. used as carriers of X.400 messages.
  357.  
  358. For example, consider Figure 1.
  359.  
  360.   -----------------------------------------------------
  361.   !                                                   !
  362.   !            PRMD A                                 !
  363.   !        --------------------                       !
  364.   !        !   o       x      !                       !
  365.   !        !                  !                       !
  366.   !        !     o        w   !                       !
  367.   !        !          z       !                       !
  368.   !        --------------------                       !
  369.   !                                PRMD B             !
  370.   !                            ------------------     !
  371.   !                            !      o     o   !     !
  372.   !    PRMD C                  !  o             !     !
  373.   !  ------------------        !      o     z   !     !
  374.   !  !       o        !        !                !     !
  375.   !  !  o        x    !        ------------------     !
  376.   !  !     o        w !                               !
  377.   !  !        o       !                               !
  378.   !  ------------------                               !
  379.   !                                                   !
  380.   !               Key: Each character on the in       !
  381.   !                    the boxes illustrates an MTA.  !
  382.   !                                                   !
  383.   !                    x: TP0/RFC1006/TCP WEP         !
  384.   !                    w: TP4/CLNP WEP                !
  385.   !                    z: TP0/CONS/X.25 WEP           !
  386.   !                    o: MTA                         !
  387.   -----------------------------------------------------
  388.  
  389.               Figure 1: A Deployment Scenario
  390.  
  391.  
  392. PRMD A has three WEPs which collectively provide support for
  393. the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks[1] Thus,
  394.  
  395.  
  396.    [1] Note: it is acceptable for a single  WEP  to  support
  397. more  than  one stack.  Three WEPs are shown in this picture
  398. for clarity.
  399.  
  400.  
  401.  
  402. INTERNET-DRAFT (OPS-1)    [Page 7]       Exp. Date: 05/10/93
  403.  
  404. PRMD A is reachable via these stacks. However, since PRMD  B
  405. only  supports  the TP0/CONS/X.25 stack, it is not reachable
  406. from the TP0/RFC 1006 or the TP4/CLNS stack. PRMD C supports
  407. TP0/RFC1006  and  TP4/CLNS.  Since  PRMD B and PRMD C do not
  408. share a common stack, how is a message from PRMD C to  reach
  409. a recipient in PRMD B?
  410.  
  411. One solution to this problem  is  to  require  that  PRMD  B
  412. implement  a  stack  in common with PRMD C. However this may
  413. not be a politically acceptable answer to PRMD B.
  414.  
  415. Another solution is to implement a transport service  bridge
  416. (TSB)  between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B.
  417. This will solve the problem for PRMD C and B.  However,  the
  418. lack  of coordinated deployment of TSB technology makes this
  419. answer alone unacceptable on an international scale.
  420.  
  421. The solution to this problem  is  to  define  a  coordinated
  422. mechanism  that allows PRMD B to advertise to the world that
  423. it has made a bilateral agreement with  PRMD  A  to  support
  424. reachability to PRMD B from the TP0/RFC 1006 stack.
  425.  
  426. This solution does not require that every MTA or MD directly
  427. support  all  stacks. However, it is a requirement that if a
  428. particular stack is not directly supported by an MD, the  MD
  429. will  need  to make bilateral agreements with other MD(s) in
  430. order to assure that connectivity from that stack is  avail-
  431. able.
  432.  
  433. Thus, in the case of Figure 1, PRMD B can make  a  bilateral
  434. agreement  with  PRMD  A  which provides for PRMD A to relay
  435. messages which arrive on either the TP4/CLNP  stack  or  the
  436. TP0/RFC 1006 stack to PRMD B using the TP0/CONS stack.
  437.  
  438. The policies described in [1] define  this  general  purpose
  439. solution.  It is a requirement that all MDs follow the rules
  440. and policies defined by [1].
  441.  
  442.  
  443.  
  444. 3.  Description of GO-MHS Community Policies
  445.  
  446. A GO-MD is a Management Domain in the GO-MHS Community.
  447.  
  448. The policies described in this section constitute a  minimum
  449. set  of  common  policies  for GO-MDs. They are specified to
  450. ensure interoperability between
  451.  
  452.     - all GO-MDs.
  453.     - all GO-MDs and the RFC-822 mail service (SMTP).
  454.     - all GO-MDs and other X.400 service providers.
  455.  
  456.  
  457.  
  458.  
  459. INTERNET-DRAFT (OPS-1)    [Page 8]       Exp. Date: 05/10/93
  460.  
  461. Policies defined below are defined in terms  of  the  words:
  462. shall, should and might.
  463.  
  464.  
  465. 3.1.  X.400 address registration
  466.  
  467. An O/R address is a descriptive name for a UA that has  cer-
  468. tain  characteristics  that  help  the  Service Providers to
  469. locate the UA. Every O/R address is an  O/R  name,  but  not
  470. every  O/R name is an O/R address. This is explained in [5],
  471. chapter 3.1.
  472.  
  473. Uniqueness of X.400 addresses shall be used to  ensure  end-
  474. user connectivity.
  475.  
  476. Mailboxes shall be addressed according to the description of
  477. O/R  names,  Form 1, Variant 1 (see [5], chapter 3.3.2). The
  478. attributes shall be regarded as a hierarchy of
  479.  
  480.     Country name (C)
  481.     Administration domain name (ADMD)
  482.     [Private domain name] (PRMD)
  483.     [Organization name] (O)
  484.     [Organizational Unit Names] (OUs)
  485.     [Personal name] (PN)
  486.     [Domain-defined attributes] (DDAs)
  487.  
  488. Attributes enclosed in  square  brackets  are  optional.  At
  489. least one of PRMD, O, OU and PN names shall be present in an  |
  490. O/R address.
  491.  
  492. In general a subordinate address  element  shall  be  unique
  493. within  the  scope  of  its immediately superior element. An
  494. exception is PRMD, see  section  3.1.3.  There  shall  exist
  495. registration authorities for each level, or mechanisms shall
  496. be available to ensure such uniqueness.
  497.  
  498.  
  499. 3.1.1.  Country (C)
  500.  
  501. The values of the  top  level  element,  Country,  shall  be
  502. defined  by  the set of two letter country codes, or numeric
  503. country codes in ISO 3166.
  504.  
  505.  
  506. 3.1.2.  Administration Management Domain (ADMD)
  507.  
  508. The values of the ADMD  field  are  decided  on  a  national
  509. basis.  Every  national decision made within the GO-MHS com-
  510. munity shall be supported by a GO-MD.
  511.  
  512.  
  513.  
  514.  
  515.  
  516. INTERNET-DRAFT (OPS-1)    [Page 9]       Exp. Date: 05/10/93
  517.  
  518. 3.1.3.  Private Management Domain (PRMD)
  519.  
  520. The PRMD values should be unique within a country.
  521.  
  522.  
  523. 3.1.4.  Organization (O)
  524.  
  525. Organization values shall be unique within  the  context  of
  526. the subscribed PRMD or ADMD if there is no PRMD. For clarif-  |
  527. ication: The following situation is legal:                    |
  528.  
  529.     1) ADMD=FUMAIL; O=FUNET.
  530.     2) ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.
  531.  
  532. O=FUNET is here a subscriber both at ADMD=FUMAIL, 1), and at  |
  533. PRMD=NOKIA, 2).
  534.  
  535.  
  536. 3.1.5.  Organizational units (OUs)
  537.  
  538. If used, a unique hierarchy of OUs shall be implemented. The
  539. top  level  OU is unique within the scope of the immediately
  540. superior address element (i.e., Organization, PRMD or ADMD).
  541. Multiple use of OUs may be confusing.
  542.  
  543.  
  544. 3.1.6.  Given name, Initials, Surname (G I S)
  545.  
  546. Each Organization can define its own Given-names,  Initials,
  547. and  Surnames  to  be  used  within the Organization. In the
  548. cases when Surnames are not unique within an O  or  OU,  The
  549. Given-name  and/or  Initial  will  be  used  to identify the
  550. Originator/Recipient. In the rare cases when more  than  one
  551. user  would  have  the same combination of G, I, S under the
  552. same O and/or OUs, each organization is free to find a prac-
  553. tical  solution,  and  provide  the  users  with  unique O/R
  554. addresses.
  555.  
  556. Either one of Given-name or Initials  should  be  used,  not
  557. both.  Periods shall not be used in Initials.
  558.  
  559. To avoid problems with the mapping of  the  X.400  addresses
  560. into  RFC-822  addresses, the following rules might be used.
  561. ADMD, PRMD, O, and OU values should  consist  of  characters
  562. drawn  from  the  alphabet  (A-Z),  digits (0-9), and minus.
  563. Blank or Space characters should be avoided.  No distinction
  564. is  made  between  upper  and lower case. The last character  |
  565. shall not be a minus sign or period.   The  first  character  |
  566. should be either a letter or a digit (see [6], [7]).
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573. INTERNET-DRAFT (OPS-1)   [Page 10]       Exp. Date: 05/10/93
  574.  
  575. 3.1.7.  Domain Defined Attributes (DDAs)
  576.  
  577. The GO-MHS Community shall allow the use of  domain  defined
  578. attributes.  Note: support for DDAs is mandatory because all
  579. software must upgrade to support DDAs.  The  following  DDAs
  580. shall be supported by a GO-MD:
  581.  
  582.     "RFC-822" - defined in [3].
  583.  
  584.  
  585. The following DDAs should be supported by a GO-MD:
  586.  
  587.     "COMMON" - defined in [2].
  588.  
  589.  
  590.  
  591. 3.2.  X.400 88 -> 84 downgrading
  592.  
  593. The requirements in [2] should be implemented in GO-MDs
  594.  
  595.  
  596. 3.3.  X.400 / RFC 822 address mapping
  597.  
  598. All GO-MHS Community end-users shall be reachable  from  all
  599. end-users  in  the  RFC-822  mail  service  in  the Internet  |
  600. (SMTP), and vice versa.
  601.  
  602. The address mapping issue is split into two parts:
  603.  
  604.     1) Specification of RFC-822 addresses seen from the X.400 world.
  605.     2) Specification of X.400 addresses seen from the RFC-822 world.
  606.  
  607. The mapping of X.400 and RFC-822  addresses  shall  be  per-
  608. formed according to [3].
  609.  
  610.  
  611. 3.3.1.  Specification of RFC-822  addresses  seen  from  the
  612. X.400 world
  613.  
  614. Two scenarios are described:
  615.  
  616.     A. The RFC-822 end-user belongs to an organization with no defined X.400
  617.        standard attribute address space.
  618.     B. The RFC-822 end-user belongs to an organization with a defined X.400
  619.        standard attribute address space.
  620.  
  621.  
  622. Organizations belong to scenario B if their X.400  addresses
  623. are registered according to the requirements in section 3.1.
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630. INTERNET-DRAFT (OPS-1)   [Page 11]       Exp. Date: 05/10/93
  631.  
  632. 3.3.1.1.  An  organization  with  a  defined  X.400  address
  633. space
  634.  
  635. An RFC-822 address for an  RFC-822  mail  user  in  such  an
  636. organization  shall  look  exactly as a normal X.400 address
  637. for X.400 users in the same organization. Example:
  638.  
  639. University of Wisconsin-Madison is  registered  under  C=US;
  640. ADMD=Internet;  PRMD=XNREN;  with  O=UW-Madison and they are
  641. using OU=cs to address end-users in the  CS-department.  The
  642. RFC-822  address  for RFC-822 mail users in the same depart-
  643. ment is: user@cs.wisc.edu.
  644.  
  645. An X.400 user in the GO-MHS Community will address the  RFC-
  646. 822 mail user at the CS-department with the X.400 address:
  647.  
  648.     C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
  649.  
  650.  
  651. This is the same address space as is  used  for  X.400  end-
  652. users in the same department.
  653.  
  654.  
  655. 3.3.1.2.  An organization  with  no  defined  X.400  address
  656. space
  657.  
  658. RFC-822 addresses shall  be  expressed  using  X.400  domain
  659. defined  attributes.   The mechanism used to define the RFC-
  660. 822 recipient will vary on a per-country basis.
  661.  
  662. For example, in the US, a special PRMD named  "Internet"  is
  663. defined   to   facilitate   the   specification  of  RFC-822
  664. addresses.  An X.400 user can address an  RFC-822  recipient
  665. in the U.S. by constructing an X.400 address such as:
  666.  
  667.     C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
  668.  
  669.  
  670. The first part of this address:
  671.  
  672.     C=us; ADMD=Internet; PRMD=Internet;
  673.  
  674.  
  675. denotes the U.S. portion of the Internet community and not a
  676. specific "gateway". The 2nd part:
  677.  
  678.     DD.RFC-822=user(a)some.place.edu
  679.  
  680.  
  681. is the RFC-822 address of the RFC-822 mail user  after  sub-
  682. stitution  of non-printable characters according to [3]. The
  683. RFC-822 address is placed in an X.400 Domain Defined  Attri-
  684. bute of type RFC-822 (DD.RFC-822).
  685.  
  686.  
  687. INTERNET-DRAFT (OPS-1)   [Page 12]       Exp. Date: 05/10/93
  688.  
  689. Each country is free to choose its own  method  of  defining
  690. the  RFC-822 community.  For example in Italy, an X.400 user
  691. would refer to an RFC-822 user as:
  692.  
  693.     C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
  694.  
  695.  
  696. In the UK, an X.400 user would refer to an RFC-822 user as:
  697.  
  698.     C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
  699.  
  700.  
  701.  
  702. 3.3.2.  Specification of X.400 addresses seen from the  RFC-
  703. 822 world
  704.  
  705. If an X.400  organization  has  a  defined  RFC-822  address
  706. space,  RFC-822  users  will  be able to address X.400 reci-
  707. pients  in  RFC-822/Internet  terms.  This  means  that  the
  708. address  of  the X.400 user, seen from an RFC-822 user, will
  709. generally be of the form:
  710.  
  711.     Firstname.Lastname@some.place.edu
  712.  
  713.  
  714. where the some.place.edu is a registered Internet domain.
  715.  
  716. This implies the necessity of maintaining  and  distributing
  717. address  mapping  tables to all participating RFC-1327 gate-
  718. ways. The  mapping  tables  shall  be  globally  consistent.
  719. Effective  mapping table coordination procedures are needed.
  720. The procedures defined in [4] shall be followed.
  721.  
  722. If an organization does not have a defined  RFC-822  address
  723. space,  an escape mapping (defined in [3]) shall be used. In
  724. this case, the address of the X.400 user, seen from an  RFC-
  725. 822 user, will be of the form:
  726.  
  727.     "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
  728.                                     some.gateway.edu
  729.  
  730.  
  731. Note that [7] specifies that quoted left-hand side addresses
  732. must  be  supported  and that these addresses may be greater
  733. than 80 characters long.
  734.  
  735. This escape mapping shall also be used for  X.400  addresses
  736. which do not map cleanly to RFC-822 addresses.
  737.  
  738. It is recommended that an organization with no defined  RFC-
  739. 822  address  space, should register RFC-822 domains at SRI-
  740. NIC. This will minimize the number of addresses  which  must
  741. use the escape mapping.
  742.  
  743.  
  744. INTERNET-DRAFT (OPS-1)   [Page 13]       Exp. Date: 05/10/93
  745.  
  746. If the escape mapping is not used, RFC-822  users  will  not
  747. see  the  difference between an Internet RFC-822 address and
  748. an address in the GO-MHS Community.  For example:
  749.  
  750. The X.400 address:
  751.  
  752.     C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
  753.  
  754.  
  755. will from an RFC-822 user look like:
  756.  
  757.     Firstname.Lastname@cpg.cdc.com
  758.  
  759.  
  760.  
  761. 3.4.  Routing policy
  762.  
  763. To facilitate routing in  the  GO-MHS  Community  before  an
  764. X.500  infrastructure is deployed, the following two tables,
  765. an MTA table and a Domain table, are defined.  These  tables
  766. are  formally  defined  in  [1].  The use of these tables is
  767. necessary to solve the routing crisis that is present today.
  768. However,  this  is a temporary solution that will eventually
  769. be replaced by the use of X.500.
  770.  
  771. The MTA table will define  the  names  of  well  known  MTAs
  772. (WEPs) and their associated connection data including selec-
  773. tor values, NSAP addresses, supported protocol  stacks,  and
  774. supported X.400 protocol version(s).
  775.  
  776. Each entry in  the  Domain  table  consists  of  a  sub-tree
  777. hierarchy  of  an  X.400 address, followed by a list of MTAs
  778. which are willing to accept mail for the address or  provide
  779. a  relay  service  for  it. Each MTA name will be associated
  780. with a priority value. Collectively, the list of  MTA  names
  781. in  the  Domain  table make the given address reachable from
  782. all protocol stacks. In addition, the list of MTAs may  pro-
  783. vide  redundant  paths  to the address, so in this case, the
  784. priority value indicates the preferred  path,  or  the  pre-
  785. ferred order in which alternative routes should be tried.
  786.  
  787. The MTA and Domain  tables  are  coordinated  by  the  group
  788. specified  in  the  Community  document.  The procedures for
  789. table  information  gathering  and  distribution,  are   for
  790. further study.
  791.  
  792.  
  793. 3.5.  Minimum statistics/accounting
  794.  
  795. The following are not required for all end-MTAs. The  infor-
  796. mation  is  provided  as guidelines for MTA managers, and is  |
  797. based on work in [8].  This is helpful for observing service  |
  798. use and evaluating service performance.                       |
  799.  
  800.  
  801. INTERNET-DRAFT (OPS-1)   [Page 14]       Exp. Date: 05/10/93
  802.  
  803. This section defines the data which should be kept  by  each
  804. MTA.  There are no constraints on the encoding used to store
  805. the data (i.e., format).
  806.  
  807. For each  message/report  passing  the  MTA,  the  following
  808. information should be collected.                              |
  809.  
  810. The following fields should be collected.
  811.  
  812.     Date
  813.     Time
  814.     Priority
  815.     Local MTA Name
  816.     Size
  817.  
  818.  
  819. The following fields are conditionally collected.
  820.  
  821.     From MTA Name (fm)
  822.     To MTA Name (tm)
  823.     Delta Time (dt)
  824.     Message-id (id)
  825.  
  826. At least one of 'fm' and 'tm' should be present.  If one  of  |
  827. 'fm'  and  'tm'  is  not present, 'id' should be present. If
  828. both 'fm' and 'tm' are  present,  then  'dt'  indicates  the
  829. number  of  minutes that the message was delayed in the MTA.
  830. If 'id' cannot be mapped locally because of  log  file  for-
  831. mats,  'id'  is  not  present  and every message creates two
  832. lines: one with 'fm' empty and one with 'tm' empty. In  this
  833. case, 'date' and 'time' in the first line represent the date
  834. and time the message entered the MTA.  In the  second  line,
  835. they represent the date and time the message left the MTA.
  836.  
  837. The following fields are optionally collected.
  838.  
  839.     From Domain (fd)
  840.     To Domain (td)
  841.  
  842. For route tracing, 'fd' and 'td' are useful. They  represent
  843. X.400  OU's,  O,  PRMD, ADMD and C and may be supplied up to
  844. any level of detail.
  845.  
  846.  
  847.  
  848. 4.  Community Document
  849.  
  850. For the GO-MHS community there will exist one single COMMUN-
  851. ITY document containing basic information as defined in [1].
  852. First the contact information for the  central  coordination
  853. point  can be found together with the addresses for the file
  854. server where all the documents are  stored.  It  also  lists
  855. network  names  and  stacks to be used in the WEP and DOMAIN
  856.  
  857.  
  858. INTERNET-DRAFT (OPS-1)   [Page 15]       Exp. Date: 05/10/93
  859.  
  860. documents. The GO-MHS community must agree on its own set of
  861. mandatory and optional networks and stacks.
  862.  
  863.                          References
  864.  
  865. [1]  U. Eppenberger, Routing coordination for an X.400  MHS-
  866.      service  within  a  multi  protocol / multi network en-
  867.      vironment, IETF  Internet  Draft,  "draft-ietf-x400ops-
  868.      mhs-service-03.txt".
  869.  
  870.  
  871.  
  872. [2]  S.E. Hardcastle-Kille: X.400 1988 to 1984  downgrading,
  873.      RFC 1328, May 1992.
  874.  
  875.  
  876.  
  877. [3]  S.E. Hardcastle-Kille: Mapping  between  X.400(1988)  /
  878.      ISO 10021 and RFC 822, RFC 1327, May 1992.
  879.  
  880.  
  881.  
  882. [4]  Urs Eppenberger, Jeroen Houttuin, Paul Klarenberg,  Jim
  883.      Romaguera:  Co-ordination Procedures for RFC 1327 Gate-
  884.      ways, (IETF Internet Draft).
  885.  
  886.  
  887.  
  888. [5]  <ref. CCITT Red Book, X.400>
  889.  
  890.  
  891.  
  892. [6]  K. Harrenstien, et al. DOD Internet Host Table Specifi-
  893.      cation.  Request for Comments 952, October 1985.
  894.  
  895.  
  896.  
  897. [7]  R. Braden. Requirements for Internet Hosts --  Applica-
  898.      tion  and  Support.  Request for Comments 1123, October
  899.      1989.
  900.  
  901.  
  902.  
  903. [8]  The COSINE MHS Project Team, "Requirements for A  Final
  904.      Format Of Traffic Statistics"
  905.  
  906.  
  907.  
  908. [9]  C. Allan  Cargille,  Postmaster  Convention  for  X.400
  909.      Operations,  IETF  Internet Draft, "draft-ietf-x400ops-
  910.      postmaster-00.txt"
  911.  
  912.  
  913.  
  914.  
  915. INTERNET-DRAFT (OPS-1)   [Page 16]       Exp. Date: 05/10/93
  916.